1. Field of the Invention
The invention described herein relates to computer graphics, and more particularly to data representation and rendering.
2. Background Art
In computer graphics, a scene can be modeled in a variety of ways. One way is through the use of a scene graph. The nodes of a scene graph represent features of the scene, such as physical objects and their attributes (e.g., colors and textures). The edges of a scene graph represent associations between the connected nodes. A node representing an object, for example, may be connected to a node representing a texture for that object. Scene graphs are often represented in object oriented languages such as C++. Scene graphs are well known in the computer graphics field, and are described in greater detail in “The Inventor Mentor” by Josie Wemecke, published by Addison Wesley, incorporated herein by reference in its entirety. An example of a scene graph is shown in FIG. 1. Scene graph 100 represents a house. The house is identified with root node 110. The house includes a number of components, such as door 120, roof 130, and aggregate walls 140. Individual walls 150 through 180 are associated with aggregate walls 140. Each wall can have some number of attributes. For example, wall 180 is shown having texture 190.
Scene graphs can be produced by a modeler. A modeler can be a person or a program that converts a scene into one or more scene graphs. A number of modelers are available commercially, such as MAX and MAYA. Ultimately, a scene graph is rendered to produce an image. This is illustrated generally in FIG. 2. Here, a modeler 210a produces a scene graph that is processed through an export library 220a. Export library 220a manipulates the scene graph to put it in a form that can be rendered by rendering platform 240. Export library 220a may include an optimizer 230a that further revises the scene graph in order to optimize the graph in some manner prior to rendering. Optimizer 230a may, for example, manipulate the scene graph so as to minimize the memory requirements during rendering, or improve the drawing time.
As shown in FIG. 2, however, a rendering platform may have to accommodate scene graphs produced by a variety of modelers. Such modelers are illustrated in FIG. 2 as modelers 210a, 210b and 210c. Each modeler sends its scene graphs to rendering platform 240, via export libraries 220a, 220b, and 220c, respectively. As discussed above, each export library may include an optimizer. The optimizers for the respective export libraries are shown as optimizers 230a, 230b, and 230c, respectively.
The arrangement of FIG. 2 is inherently redundant and inefficient. The export libraries and their optimizers perform analogous functions. The code representing software embodiments of the export libraries and optimizers is therefore repetitive. Hence, there is a need for a common export library and, in particular, a common optimizer that can process the scene graphs produced by a variety of modelers such that the resulting scene graphs are tailored to a particular rendering platform.